<?xml version="1.0" encoding="UTF-8"?>
<!--

       Copyright 2006-2016 the original author or authors.

       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

       Unless required by applicable law or agreed to in writing, software
       distributed under the License is distributed on an "AS IS" BASIS,
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.

-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Philosophy and Apology</title>
    <link rel="stylesheet" type="text/css" href="mbgstyle.css"/>
</head>
<body>
<h1>Philosophy and Apology</h1>
<p>Some philosophical questions might be raised by this tool because the
    tool is more focused on database tables than on the domain model.
    We will take a few paragraphs to talk about this approach.</p>

<p>First of all, this tool does what it does. We are not making any kind of statement
    about how projects should, or should not, be structured. In general we are strong proponents
    of rich domain models - but creating a rich domain model is quite a different thing from
    answering the question of how that model should be persisted.</p>

<p>If your particular design philosophy is that the domain model drives all decisions, and
    that the database design is subservient to the domain model, then this tool - and MyBatis
    itself - may not be the proper fit for your application. In that case, we would suggest
    taking a serious look at <a target="_blank" href="http://www.hibernate.org">Hibernate</a>
    - it may fit
    more closely with your application design and philosophy.</p>

<p>But not all projects fit that paradigm. Very few truly enterprise
    class applications do. MyBatis can be of great help in projects where
    database design is seen as a co-equal to domain object design.
    MyBatis is not an object relational mapper, and does not attempt to transparently
    persist objects. So it falls on application developers to write SQL to interact with
    database tables.</p>

<p>In large or enterprise class projects, many of these factors are quite common:</p>
<ul>
    <li>Database design is often a separate function (with separate management) from OO domain
        design
    </li>
    <li>Database designers do not have OO tools (like inheritance), so they don't think
        in OO terms
    </li>
    <li>Application designers do not have complete control over the final form of database tables.
        For example, the data that seems to fit in one object for the application, may be split
        into several tables in the database.
    </li>
    <li>The database design often ends up quite different from the OO design, leading to
        a significant mismatch between tables and objects.
    </li>
</ul>
<p>
    These factors are primary indicators that MyBatis is a good candidate tool for your
    application, and this is the type of project where MyBatis Generator can make a significant impact.
    So how should MyBatis be used in this case?</p>

<p>The Data Access Object(DAO) pattern is still a primary pattern. MyBatis Generator can generate a basic
    set of objects that match each individual table. Generated code is transaction neutral. This means
    that it is easy to extend the generated code to add transaction attributes if more than one table is involved in
    a transaction. Or, you could create another DAO (or service method) that more closely matches the
    persistence needs of a domain object
    and make use of one or more generated objects in a single transaction.</p>

<p>As an example, consider a typical <code>Order</code> object - the typical header/detail problem.
    In some environments such an object would be persisted into at least 4 tables -
    two key tables, a "header" table, and a "detail" table (again, we are not making any kind of
    statement about whether this is "correct" design, just stating a fact).
    Your application should still interact with interact with the <code>Order</code> object, and
    there might
    be a <code>saveOrder(Order order)</code> method
    somewhere (in an OrderDAO, or a service object). That method
    would interact with the generated code for each of the 4 tables involved.</p>

<p>What has code generation bought us in this case? Several things:</p>
<ul>
    <li>Reuse - it is likely that some tables will need to be accessed from multiple different DAOs
        or service methods. Creating a DAO for each table promotes reuse and consistency within the
        application.
    </li>
    <li>Database abstraction - a service layer typically defines persistence in your application. Those
        methods can be stabilized fairly quickly. As database design evolves:
        <ol>
            <li>Code can quickly be regenerated as the tables change</li>
            <li>The service methods can be modified as necessary</li>
            <li>Higher layers in the application remain unchanged</li>
        </ol>
    </li>
    <li>Developer productivity - generating table based DAOs is quick and repeatable and error free.
        Developers can concentrate on Object persistence, and on complex join queries if needed.
    </li>
    <li>Fewer defects - because the most tedious and error prone part of any application (getting the
        SQL to match the objects) is automated.
    </li>
</ul>
</body>
</html>
